Fix for usage server getting stuck due to duplicate VM events#13019
Fix for usage server getting stuck due to duplicate VM events#13019abh1sar wants to merge 3 commits intoapache:4.20from
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.20 #13019 +/- ##
=========================================
Coverage 16.26% 16.27%
- Complexity 13433 13439 +6
=========================================
Files 5665 5666 +1
Lines 500530 500557 +27
Branches 60787 60789 +2
=========================================
+ Hits 81411 81444 +33
+ Misses 410027 410009 -18
- Partials 9092 9104 +12
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@blueorangutan package |
|
@sureshanaparti a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 17484 |
DaanHoogland
left a comment
There was a problem hiding this comment.
@abh1sar I do not think this change is the best way to go. First an upgrade patch for minor version should be implicit, expecially if no actual changes are in the specific upgrade script. Second, the create schema script should be for 4.0 and all other changes should be entered in the upgrade scripts.
|
|
@blueorangutan package |
|
@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 17506 |
Description
This PR fixes #12590
Fix is to remove the unique key constraint from the
usage_vm_instancetable.The constraint is not required, and can cause issues with usage processing.
The other helper tables either don't have a constraint or duplicate events cannot happen as the event is generated only at create.
In case of VM instance the event is generated at every Start which makes it susceptible to duplicate events.
Added change in the upgrade path as well as in
create-schema-premium.sqlTypes of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
To test, I added 2 VM.START events to the usage_event table with the same

createdtime (id 18 and 20) and set theusage.stats.job.aggregation.rangeto 5 (minutes)Without the fix the usage server was stuck processing that interval

After removing the unique constraint, usage server finished successfully and generated the correct usage.

How did you try to break this feature and the system with this change?